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SHI 



1*1 INI&QQUCIXQIi 

The purpose of this SDM USERS GUIDE is to set forth the 
procedures* techniques* and toots to be used by SDD (Sunnyvale 
Development Division) personnel in developing Advanced Systems 
Release 2 software products. 

The primary purpose of an SDM is to assure that a project Mill 
meet requirements on schedule and within budget* as agreed to 
between management and the project. 

The SDM proposed in this document is an evolutionary outgrowth 
of SDMs in use in Control Data since the early 1970s [Peterson 
1973, Metzger 19733. 

This document* to the extent that it conflicts with Corporate 
Standard 1.01.106 "Software Development Model", constitutes a 
proposal to update the methodology of that Standard, insofar 
as that Standard is applicable to the development of Systems 
Software. 

While this document is concerned with current practices in 
SDD, it is more concerned with how current practices can be 
shaped into a coherent and systematic SDM. 



1.2 MtUI.XS.SJ>SI 

SDM is the family of internal documents, techniques, and tools 
by which requirements become design and design becomes 
releasabie code supported by published external documents. 

For the Sunnyvale Development Division, requirements, design, 
implementation, evaluation, and publication activities are 
recorded in the following family of documentss 

a. Requirements documents {controlled via DCS) 

- AO/R (CY180 Architectural Requirements/Object Ives I 
SIS (System Interface Specification) 

— GDS (General Design Specification) 
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— DR (Design Requirements) 

-■ ERS (External Reference Specification) 

b. Design documents (controlled via DCS) 

GID (General Internal Design) 

c. Implementation documents (code controlled by code 
transmittal and PSR procedures* documents via DCS) 

PL (Program Library of documented source code) 
PSR corrective code 

- Baseline documentation changes 

-■ IMS (Internal Maintenance Specification) 

d. Evaluation documents (PSTP controlled via DCS* others 



controlled by management procedures) 

- PSTP (Product Set Test Plant 
Release) 

- BER (Build Evaluation Report) 

- Approved Reviews (by Development and 
of Publications drafts of manuals. 



for each code 



Eval uati on) 



e. Publications (controlled by Publications procedures) 
-■ Reference Manuals 

- Operators Guides 

— Installation Handbook 
-■ Users Guides 

"Instant" Reference booklets 

While the generation of these documents is basically 
chronological due to logical dependencies inherent in the 
order given above* there is also an iterative process at work 
because as we learn more* we may have to revise previous 
documents. That is* requirements "drive" design and design 
"drives" code. However* refinement of design can lead to 
revision of requirements* and refinement of code can lead to 
revision of design (and sometimes* revision of requirements). 

Many of these documents are referred to as Baseline Documents* 
which a,re of two kinds? internal and external* subject to 
different sets of policies. 

Internal Baseline documents ares 

- AQ/R 

- SIS 

- GDS 
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- DR 

- ERS 

- GID 

- PSTP 

-■ IMS 

External Baseline documents are products of Publications: 

- Reference manuals 

- Operators guides 

- Installation Handbook 

DAPs are usually generated during the Analysis and Design 
activities* each DAP addressed to a particular issue. The 
author of a DAP should identify in the DAP the sectionts) of 
baseline document(s) which will be modified if the DAP is 
approved. The content of an approved DAP should result in a 
BSL Cbaseline change) with change pages to an internal 
Cpossibly external) baseline document. 

QSSs {Quotation Special Software) and RSEs (Request Software 
Enhancement) which become features of standard software should 
be handled as are DAPs. A BSL with change pages for affected 
documents should be generated. 



1.* £Q£mR£-fi£mQ£IEUiI-P!iASES 

Initial development phases are product/project oriented for a 
given version or releases 

- Feasibility Phase 

- Definition Phase 

- Analysis Phase 

- Design Phase 

- Implementation Phase 
phases (plus the Feature Test 



These 

oriented) are covered in the Project 



Pi an. 
Plan. 



which is product 



Concluding development phases are Product Set oriented toward 
a particular release: 

- Evaluation Phase 

• Publications Phase 

- Release-activity Phase 

In the pastt maintenance has sometimes been considered a 
fol low-on phase. However. for Advanced Systems* ADSC is 
directing that maintenance be handled In the same way that a 
new version would be: Go back to the Feasibility Phase and 
cycle again through all phases in an orderly manner. This 
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procedure should aid the preservation of structural integrity* 
which tends to erode over time CBelady 1979* VanHorn 19803* 



1 (Definition Phase 



a* Feasi bi I I ty Phase 

- Deliverable documents are? 

- Project Plan* chapters 
Plan) and 7 (References) 

GDS (first version) or other documentation 
describing the product in general terms for 
PLM and Marketing approval 
Feasibility phase begins when 

preparation of a GDS or 
for submission to 



The 

initiates the 

documentati on 

Marketing* 

The Feasibi 1 1 ty 



Management 
equi val ent 
PLM and 



Phase 



when 



al I 



concludes 
deliverable documents are approved* 
GDS (at least a first version) is preferable to an 
ad hoc document because a GDS will be produced 



later any way* based 
However* conditions 
hoc documents may be 
circumstances than a 
The purpose of the 
determine that there 



upon the ad hoc documents* 
vary among projects* and ad 

more suitable to particular 

GDS* 
Feasibility phase is to 
Is a need in the CDC product 



line for the proposed product* and to reach a 
general consensus upon the requirements for* and 
the architecture of* the proposed product* 



2 (Analysis Phase 



when 
ei ther 



management 
del i verable 



b. Definition Phase 

Deliverable documents are: 

- Project Plan* chapter 
Plan) 

- GDS (final version) 

- The Definition phase begins 
initiates the preparation of 
document* 

— The definition phase concludes 
deliverable documents are approved* 
The purpose of the Definition Phase is to define 
features* performance* and architecture of the 
product in sufficient detail to provide direction 
to the Analysis phase* during which all 
requirements will be explicated* 



when 
to 



al I 



Analysis Phase 

- Deliverable documents ares 

- Project Plan* chapter 

- DR 



3 (Design Phase Plan) 
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- ERS 

- GID chapters l» 2* 3* and 5 (Analysis Spec 
and Data Dictionary) 

- The Analysis Phase begins when management 
initiates the preparation of one or wore of the 
Analysis Phase deliverable documents* based upon 
evidence that the GDS is sufficiently stablized to 
provide direction for the Analysis Phase. 

The Analysis Phase concludes when all deliverable 
documents are approved. 

The purpose of the Analysis phase is to make 
explicit all feature requirements* performance 
requirements* interface requirements* and to 
insure that the proposed product architecture 
supports all known requirements and ait envisioned 
future features and future requirements. 

d. Desi gn Phase 

- Deliverable documents are: 

Project Plan* chapter 4 (Implementation 
Phase Plan* and chapter 5 (Feature Test 
Plan) 

- GID chapter 2 (Design Spec and revised Data 
Dictionary) 

- Internal and external document BSLs required 
by Publications for manuals supporting 
releasable code. 

- The Design phase begins when management initiates 
the preparation of either deliverable document* 
The Design phase concludes when al I del i ver abl e 
documents have been approved. 

The purpose of the Design phase is to document 
explicitly the design of the product prior to 
coding. 

e. Implementation Phase 

- Deliverable documents are? 

Sourse code PL 

- IMS 

-■ Reviews of drafts o 
manual s 

- The Implementation phase 
initiates it. 

- The Implementation phase 
deliverables are approved. 

- The purpose of the Implementation 
generate releasable code that 
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documentation supporting the successful completion 
of their tasks. 

f. Evaluation Phase 

-• Deliverable documents ares 

Project Plan chapter 5* Feature Test Plan 

- PSTP {Product Set Test Plan* formerly System 
Test Plan in SDD) 

- System Test Plan (ARPD) 

- Test base programs and data 

- 8ER IBuitd Evaluation Report) 

- Testing activities are of two kinds* preparing 
test plans and tests* and testing code. 

- Feature Test planning begins with the 
preparation of the Project Plan chapter 5 
(Feature Test Plan!* and continues with the 
generation of test code and data. 

- Product Set Test Planning begins when 
management initiates the preparation of the 
PSTP (based upon all Feature Test Plans of 
all products of the set)* and continues with 
the generation of test code and data. 

- System Test planning begins when management 
initiates the preparation of the System Test 
Plan. 

- Testing of code begins when management 
initiates the testing of transmitted PL or 
PSR code for a release* 

Testing phase for a release concludes when 

management accepts the BER and approves code for 

release. 

The purpose of the Feature Test Phase is to insure 

that the product code performs correctly according 

to functions specified in the requirements 

documentation and the publications. 

- The purpose of Product Set Testing (SDD) is to 
insure that the versions of products in the 
to-be-released set function together correctly. 
The purpose of the System Test Release activity is 
to insure that all of the software of the Release 
operates together as a system and meets 
performance requirements. 

g. Publications Phase 

- Required deliverable documents ares 

- Manual s Test PI an 

Reference Manuals (or Release Revision 
packets) 
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- Operator Guides 

-■ Installation Handbook 
Optional deliverable documents ares 
-■ Users Guides 

- Instant Reference booklets 

The Publications phase for a release begins when 

management initiates preparation of (or revision 

of) a document* following receipt from Development 

or Design of supporting documentation (e.g.* an 

ERS) to warrent publications activity and 

providing resources are available. 

The Publications phase for a code release ends 

with submission of manual originals to Corporate 

Printing. 

The purpose of the Publications Release activity 

is to support released code with external user 

manuals. 



h. Release-activity Phase 
Deliverables 

— PLs available 



SMD 



(Software 



from 
Manufacturing Division) 

- External Publications manuals are available 
from LDS (Literature Distribution Service) 

- All Release Bulletins are available: 

SA8 (Software Aval I abi 1 i ty Bui I eti n) 
SR8 (Systei Release Bulletin) 
FAM ( Feature Abstract Memorandum) 
The Release Phase begins when management initiates 
steps to move the deliverables from Development* 
Evaluation? and Publications to the organizations 
that distribute the deliverables to customers. 
The Release Phase concludes when release materials 
are delivered to customers* 

The purpose of the Release Phase is to insure that 
customers receive timely and coordinated service 
In connection with new releases. 
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2.0 Qt£St£LOEHEIiI.£H'Al£S 



SSH1 



2.1 ££ASiaiLIII«£aAi£ 

The purpose of the Feasibility Phase is to explore the 
feasibility of a proposed product or product enhancement from 
the joint viewpoint of Marketing* PLM* and Development* 
"Feasibility** here means "market feasibility* 1 Cis there a 
profitable market for the proposed product?) rather than 
••engineering feasibility** <can the product be built to 
specifications?)* which is explored in the Definition Phase* 

For some products* such as those for which there is agreement 
to meet an existing ANSI standard* the Feasibility and 
Definition phases are relatively brief * For other products* 
such as Data Management and Networks* there may be much effort 
required to define a product well enough to provide design 
direction for the preparation of Analysis Phase documents (DR. 
ERS* etc.). This preanalysis activity may not divide cleanly 
between Feasibility and Definition* but generally Development 
activity on a SDS sufficiently detailed to win approval cannot 
begin until PLM and Marketing have established the market 
feasibility for the proposed product or proposed product 
enhancement* 

If the proposal is deemed feasible* then Development 
deliverable documents of the phase are: 

— ■ Project Plan chapters 1 and 7* 

- GDS f initial version! or other documentation describing 
the product in general terms* for Marketing and PLM 
approvals* 



The intent 
Definition 



of the 
Phase* 



documents is to provide direction to the 



The primary activity of the feasibility phase will probably be 
an exchange of memos among interested parties concerning 
features* architecture* performance* and interfaces to other 



products which constitute a goal for 
be of permanent value* the outcome 
should be recorded in the GDS or 
approved by PLM* Marketing* and AHPD 



a feasible product* To 
of this exchange of memos 
other documents to be 
and/or SDD* 
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2.2 QEEiiilllQii-EtfASE 

Development deliverables of the definition Phase are: 
Project Plan chapter 2 (Analysis Phase) 
- GDS (final versionl 

The purpose of the Definition Phase is to firm up the 
decisions of the Feasibility Phase into a coherent set of 
requirments (features* per formance* architecture* interfaces 
to other products) in a approved GDS. The object (or goal) is 
to provide a definition of the product and to provide design 
direction for the Analysis Phase. Prior to the beginning of 
the Definition phase* design direction is not firm enough to 
result in an approved GDS* for PLM and Marketing are still 
determining the market feasibility of the proposed product. 
There may also be budgetary considerations that restrict the 
resources aval lable to prepare a GDS* and these considerations 
may also delay the transition from the Feasibility Phase to 
the Definition Phase. 



Reuqirements analysis is one of 
software development activities 



the most difficult 
CBoehm 19793. 



of alt 



which seems to 



Requirements analysis is an art* not a science* 
use the following sort of dialectical process? 

1. The designer or design team* on the basis of the best 

and most complete information available* proposes to the 

customer(s) a design thought to meet all requirements in 

an optimum fashion. 

The customer says the design will not do because*. •* and 

another requirement which the designer was unaware of 

(and possibly the customer too unaware of before 

thinking about it) crawls out of the woodwork. 

The designer reworks the design* possibly from 

but more likely by patching it* 

1. 

The customer says that will not 

to step 2. 

and the process iterates on and 
designer is lucky* the process 



2. 



3. 



4. 



« * 
the 



and goes back 
due because...* 



scratch* 
to step 

and back 



If 

set of requirements (features* 

interfaces to other products). 



on. 
terminates 



performance* 



in a coherent 
archi tecture* 



However* every requirement has a price and if the price is too 
high (low priority item conflicts with a high priority item* 
architectural structure is compromised* implementation cost is 
too much* etc.)* the "requirement" ceases to be a requirement* 
no matter how tenaciously held theretofore. 
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2.3.1 INTRODUCTION 

The purpose of the Analysis Phase is to finalize requirements 
and to carry design far enough to insure there are no design 
problems in meeting the requirements spelled out in the DR* 
the ERS* and the Analysis Spec portion of the GID. 

Development deliverables are: 

- Project Plan chapter 3 

- DR 

- ERS 

- GID chapters 1* 2* 3* and 



5 (Analysis Spec) 



If the software research literature is correct in claiming 
that a requirements bug caught after del i very of a product to 
a customer costs 270 times as much to fix as a coding bug and 
that a design bug costs 90 times as much to fix CMcCabe 19801* 
then Control Data should be able to save many maintenance 
dollars by doing a better job of generating and reviewing 
requirements and design documents. 

SASD (Structured Analysis/Structured Design* CDeMarco 1978* 
Yourdon 19781) emphasizes the difference between data flow 
analysis (a definition and requirements function) and 
structured design Ca design function). 

Experience with SASD during development of Advanced Systems 
Release 1 products resulted in very few products doing both 
data flow and structure charts. Projects converting from 
CY170 had worked out their requirements during CY170 
development and had little need of data flow analysis. 
Structure charts* on the other hand* turned out to be useful 
for documenting design* though some projects found other 
techniques* such as state tables* of more value. 

For Release 2* there are several techniques available* each 
with advantages and disadvantages relative to the differing 
needs of various projects. 

Beyond Release 2* it may be possible to use a specification 
language (such as 8SL CBarber 19813) for analysis/design. 
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2.3.2 SA (STRUCTURED ANALYSIS) 

Structured Analysis las defined and described by DeMarco) 
offers useful techniques of decomposition* data 
transformations* and data dictionary. 



Decomposition is the technique 
program in a one-page context 
interfaces to other programs) and 
then decomposing each process in 



of summarizing an entire 

chart (to show data flow 

a one-page level DFD* and 

the level DFD into level 1 



DFDs* and so on down to as many levels as are necessary to 
define each bottom-level process in structured English. 

Data transformation is technique of showing (with 
decomposition of data: files into records* records into 
segments* segments or tables into data elements) how output 
data is derived (directly or indirectly) from intermediate 
files or tables and input data* and how intermediate files and 
tables are updated frOra input data. 



A data dictionary 
aggregations. 



defines all data elements 



and 



data 



Structured Analysis can be of great 
defining the functions to be performed 
interface requirements of users and 
understood by the project and can be 
project. 



help to a project in 

and insuring that 

other products are 

implemented by the 



SA is supported by computer tools. The Data Dictionary CDCS 
ID*ARH39801 supports data descriptions and process 
descriptions. SASD Graphics CDCS ID*ARH39813 supports Data 
Flow diagrams. 



2.3.3 IA (INFORMATION ANALYSIS) 

Information Analysis offers the capability of defining data 
and the forms of data permissible during data 
transformations. It does not offer decomposition techniques* 
though IA can be used to define data at any level from the 
most abstract to the most detailed. Nor does IA offer the 
capability to define data transformations (i«e«* the algorithm 
by which an output or file item is constructed from input or 
other f i le items) . 

Information Analysts may be useful for projects whose main 
task is to describe a data base (e.g.* the IADT project* the 



H3 
I 

SI 



SI 



SI 
SI 



SI 



H3 
I 



SI 



1 
2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 



revision B 



USERS GUIDE 

SOFTWARE DEVELOPMENT METHODOLOGY (SDM) 



2-5 
09/23/81 



2.0 DEVELOPMENT PHASES 

2.3.3 IA (INFORMATION ANALYSIS) 



CODE 



12.38,58. 

LINE 



SASD database to support Graphics 
Corporate Traffic project). 



and Data Dictionary* the 



IA is not supported by computer tools. IAF and ADAM are 
available for implementation* but are rather complex to use as 
Analysis tools. 



2.3.4 STATE TABLES 

State tables are a useful tool for complex programs where the 
reaction to a given Input is a function of the internal state 
of the program. State tables have been used by Networks (to 
define protocol-driven programs) and Fortran/VS (to define 
symbol table processing). State tables can be very helpful in 
uncovering error cases* end cases* and infrequent cases that 
may be overlooked in the course of design* because the 
technique forces a took at all possible inputs for all 
possible states. 

While there Is no computer tool specifically supporting state 
tables* the Graphics structure chart capability can be used. 

2.3.5 DECISION TABLES 

Decision tables can be useful* for the same reasons that state 
tables can be. Essentially* a decision table is appropriate 
for a program that has only one state for a given set of 
inputs. For these cases* all data input/output cases can be 
def ined. 

In the computer industry* there are COBOL-related decision 
table tools* but none seems widely used In Control Data. 



2.3.6 STRUCTURED TESTING 

Structured Testing CMcCabe 19803 offers several techniques for 
checking requirement specifications: 

- Cause and Effect graphs Cpp 11-11* II-12M For each 
cause mentioned In the ERS or Analysis Spec* there 
should be one or more causes; for each effect there 
should be one or more causes; and these should be 
coherent (specified by non-conflicting and/or 
conditions). 

- Specification reviews ipp 11-18 thru 11-26) to insure 
specifications are complete and coherent. 
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2.3.7 DATA FLOW ANALYSIS VERSUS STRUCTURE CHART ANALYSIS 

It seems to be a latter of individual temperament that some 
programmers prefer data flow analysis while others prefer 
structure design. Few programmers seem temperamentally 
equipped to view both as equally useful. This difference 
seems to have roots in a preferred position either that 
control flow is the logical consequence of data flow* or that 
data flow ought to be the logical consequence of control flow 
(i.e.* which has logical precedence: data flow or control 
flow? which is the boss* from a requirements point of 
view?)* 

The challenge of the Analysis Phase is to make sure that data 
flow requirements are understood prior to detailed design* 
otherwise the detai led desi gn may not be able to support the 
requirements of the program. Hence DeMarco , s plea to set 
aside design until data flow has been analysed to the point 
where those specifying requirements have agreed that the 
proposed specifications meet the requirements* 

The crucial point is that the DR and ERS not be subject to 
modifications during the design phase* due to either 
management or the project having overlooked or misunderstood 
requirements. 



2.4 aESI£&-EHA£E 

The purpose of the Design Phase is to complete design prior to 
Implementation (coding and unit test). 

Development deliverables are: 

- Project Plan chapter 4 

- GID (final version) 

-■ BSLs for internal and external baseline documents 

Evaluation deliverable: Project Plan chapter 5 

Publications deliverable: Manuals Test Plan 

SD (Structured Design) is the principal methodology of design* 
as spelled out by Yburdon and Constantino. 

SD is supported by the SASD Graphics for SCTs (structure 
charts) and the SASD Data Dictionary for module descriptions. 
Module descriptions should be detailed enough so that there is 
no ambiguity or open question encountered by the programmer 
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Mho translates the nodule description into code meeting CYBIL 
coding standards* This does not necessarily mean that the 
module descriptions are so detailed that each structured 
English statement Is the equivalent of one or a few lines of 
code* 

Structured Testing CMcCabe 19803 provides quidelines for 
reviewing design documents Cpp IV-20 thru IV-36)* 

It is recommended that each project prepare a Project Notebook 
setting forth procedures that all project members sre expected 
to adhere to (e.g.* "NQS/VE Project Procedures and 
Conventions*) • 



2 . 5 ifi£t£MEiiIAIIQli.£tlAS£ 

The purpose of the Implementation phase is to generate code 
which has been reviewed and unit-tested (Development) * to 
generate test programs and data (Evaluation)* and to generate 
drafts of external manuals (Publications)* 

Development deliverables are: 

- Source Code PL 

- IMS 

Evaluation deliverables are: Test programs and data 

Publications deliverables ares Drafts of external manuals 

Coding and code reviews wl I be done in accordance with 
SOD/ARPH coding staandards and procedures* 

The project should insure that the procedures of the Project 
Notebook are adhered to (or revise the procedures so that they 
are adhered to)* 



2.6 MAUIAIIM-EHASE 

Historically* the function of Software Evaluation has been to 
detect errors before a customer did* so Software Development 
could correct bugs before the software was submitted to an 
acceptance test or installed at a user's site CMetzger 19731* 
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While some persons look to proper design to result In bugless 
code and a program that never had any bugs is a better program 
than one in which the bugs have been fixed CMills 19763* 
others believe that the proper function of Evaluation is to 
pinpoint the origin of errors in the development process so as 
to debug the development process CDeming 19813. 

"During July 1981* Dr W Deming* the man whose ideas inspired 
the revolution in quality in Japanese industry conducted a 
four-day seminar for Control Data. He said* 

- 85% of product defects arise from the process that 
produces the product* not from the workers who 
immplement the process* 

- Everyone is already doing his "best". If you want fewer 
defects* you have to find a better process. 

- If you reach your current level of defects through test 
and rework* you can find a process that 

— achieves the same level of defects directly* 
without test and rework and 

— is more profitable than your current process. 

- If you search for it* you can eventually find a process 
that 

— produces no defects 

— is more profitable than your current process. 

- The best use of your testing process Is to determine the 
capability of your process tits inherent defect level) 
so that you can improve It.** CHuntwork 1981* page 5.2.11 

If these remarks are to be taken seriously* then for Release 2 
the various test plans should address how Evaluation will 
determine which part of the development process is 
contributing to each error encountered. In the literature of 
Software Engineering* these problems are discussed in CBoehm 
19751 and CBoehm 19763* among other places. 



Test plans ares 

- Project Plan chapter 5 

- PSTP (Product Set Test 
-■ System Test Plan* AHPD 



Feature Test 
PI an I* SDD 



Sources of errors to be identified includes 

- Requirements activity 

- Design activi ty 

- Implementation activity 

- Publications activity 

- Evaluation activity 

Within each of these activities* a possible source of error 
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might be* 

- omission or oversight 

- mi sunder standing 

- poor documentation in 

- poor documentation or 
document 

- ••fell between the cracks" 
deficient 



a baseline document 

documentation in 9t\ inappropriate 

and some aspect of SDM is 



2.7 EUfiLKAIISBS-EttASf 

The Publications and Graphics Division has procedures for 
generating external baseline manuals and other manuals for the 
planned code release* 

Development management and Publications management work 
together to establish a schedule such that both groups can 
meet their commitments for release* 



Major items of 

been mentioned 

- Internal 

schedule 



the interface between Development and Pubs have 
in the phases above: 

baseline documents must arrive in Pubs on 
inorder that Pubs prepare draft manuals on 



schedule* 

- BSLs to external baseline documents must arrive in Pubs 
on schedule inorder that Pubs prepare draft 'manuals on 
schedule* 

- Pubs drafts of manuals must arrive in Development on 
schedule inorder that Development and Evaluation can get 
reviewed drafts back to Pubs in time for Pubs to make 
changes and still meet the Release schedule* 

The key document in providing this schedule is the Pubs 
"Manual Test Plan" prepared by Pubs during the Design Phase* 
with appropriate input from Development management* 



2 . 8 E£L£ ASErAamiX-£aAS£ 

Timely release of materials to customers entails much 
coordination among Development* Evaluation* Publications* 
Software Manufacturing* and Literature Distribution* 

The procedures for these activities are spelled out in the SDD 
Mini-procedures Handbook* 
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3.o aoauaEtiis 



SHI 



For each document* a brief description is given* followed by a 
table of contents* Where appropriate* these skeletal tables 
of contents are based on CDC Standard 1.01.100 "Programming 
Project Management Standards". 



NOTE for any 
Dictionary for 
defines technical 
document. 



3.1 MMECI-EUtt 



document containing a glossary: The ANSI 

Information Processing (ANSI X3/TR-1-77) 

terms not defined in the glossary of the 



Purposes 



To describe an activity in terms of how it is to be 
done* when it will be done* what the cost will be* 
what other projects are constrained* and what are 
constraining projects* 

The Project Plan is a management document rather 
than a technical document. It should include a 
minimum of technical detail about the product. 

The Project Plan is included in this USERS GUIDE in 
order to* 

Standardize the format among 

- Indicate the sequence in 

should be written* and 

chronological relationship 

chapters with other documents 



SDD projects 
which chapters 
indicate the 
of Product Plan 



Contents 



The project plan is the controlling project 
document and contains several parts* These include 
Call may not be required for a given project)! 

Chapter 1 — Definition Phase Plan 

Chapter 2— Analysis Phase Plan 

Chapter 3— Design Phase Plan 

Chapter 4 — Implementation Phase Plan 

Chapter 5 — Feature Test Plan 

Chapter 6— Post Hot tern 

Chapter 7-~Ref er ences 
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Audience: 



Owner * 



Author: 



Comments: 



Managers 
PI anners 

Interfacing projects 
System test 
Development project 
Quality Assurance 



SDD Management 



Project/Product Design (chapters 



Development 

1,2*3*7) 

Development Project (Chapter 4) 

Evaluation (Chapter 51 

Development Project/Product 

(Chapter 6) 



Design/Evaluation 



All the planning documents* as Hell as the post 
mortem* are included in this one plan* This makes 
the project plan more complete and meaningful. 
Since it is organized into chapters* the audience 
can go directly to the part that is of 
Most of the chapters above are based on 
that used to be stand-alone. Due to the 
these were stand-alone* a great deal of 
was noted. Collapsing the documents 
el i minates this problem. 



interest, 
a document 
fact that 
redundancy 

into one 



The Definition Plan describes objectives* 
deliverables* and schedules for the definition 
phase. The Analysis Plan does likewise for the 
Analysis phase. The Design Plan consists of 
objectives* milestones* and resources needed for 
the design activity. The Implementation Plan 
contains similar types of information* plus 
constraints* risks* unit testing plans or 
direction* and System Integrated Test CSITI plans* 
if required. Descriptions of individual unit tests 
in the form of a matrix or a list will be produced 
by the project and/or the design team. These 
details need not be part of the IPP. The Feature 
Test Plan describes the activities to be performed 
by Evaluation to verify functional capabilities of 
a given product or feature* as well as activities 
required to verify the product performance 
requirements as specified in the AQ/R and the DR. 
The Feature Test Plan also lists resource 
requirements* constraints* risks* and testing 
milestones. Plans for performing System Integrated 
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Test (SIT! cycles should also 
appropriate. SIT plans should 
the SIT plans outlined in Chapter 
plan. As with the IPP* specific 
and/or a test matrix are provided 
project or by the design team as 
document; these details need not 



he included* if 
be in response to 
4 of the project 
test descriptions 
by the evaulation 
a separate working 
be part of the 



FTP. The post mortem is an informal document that 

describes what went right with the project* what 

went wrong with the project* and what could have 

been done to rectify bad situations in the 
project* 

Each chapter of the project plan can be considered 
either as a stand-alone document or as a part of 
the whole. Chapters are completed and distributed 
at different points in time* and* in the case of 
the Feature Test Plan* are authored by different 
people. Note that information is not repeated in 
each of the chapters. For example* for each 
chapter that contains milestones* the choice of 
milestones should be only those needed by people 
other than the author and the author's manager* for 
example* inter dependency milestones* In chapters 
1» 2f and 3 only start and complete dates may be 
required. Intermediate milestones are not of 
general interest and quickly become obsoleted by 
the PERT. 



Table of Contents? 

1.0 
1.1 



Def ini tion PI an 

Introduction 

Introduction to and summary of chapter 1. 

Relevant documents can be listed here or in 

chapter 7. Can contain a short technical 

description of the product* especially if 

the GDS does not yet exist. 

1.2 Deliverables 

Project Plan chapter 2 (Analysis Plan!* GDS* 
and any other deliverables. 

1.3 Milestones 

Dates for start* DCS submittal* and approval 
of each deliverable document. 
1*4 Resources and Schedule 

Identify person/months of effort for each 
calender month for each deliverable. 
Identify any other resources nee^ for the 
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Constraints 

Identify any constraints upon schedule and 

resources. (These constraints apply to the 

phase resources and schedule* not to the 

product. J 
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This chapter is the result of meetings with 
development* integration* evaluation* 
product design* and publications personnel 
who were involved with the project. Topics 
to be covered should include: 

Analysis Phase/Design Phase of the 

project 
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- Total Project Cost Data 
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as well as product-wide scale; to be used as input 
to the DR and the test plans. 
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system In specific terms* and furnishes detailed 
specifics of the sytem definition. 
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4.0 Master Project Authorization 
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D. Other 
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manuals. The DR and GDS are inputs to the ERS. 

Managers 

Development Project 
Evaluation 
Product Design 
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Table of Contents* 

1.0 Introduction 
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A brief statement describing the software 

and I ts purpose. 

References 

Feature Description 

Feature Name 

Abstract 

Give a brief and concise description of the 

feature. 

Description 

Completely define the feature in detail* 

Include a description of its function and 

possible usage* a definition of the 

variables and options applicable to the 

feature* results expected from correct use 

of the feature* dependencies of this 

feature on other features. 

Interfaces 

Identify and discuss any component 

interfaces with the user* his program* or 

the operator that are created or affected 

by this feature. Include input and output 

formats of the feature. 

Aborts and Recovery 

Discuss the manner in which the software 

and/or system nil! react in abort 

situations that are caused by this 

feature. Include reaction of this feature 

to system and user initiated aborts. 

Performance 

Discuss how this feature will affect the 

performance of the component* software 

product or overall system* from an external 

point of view* if it is helpful for the 

user to know it. Don»t get into internal 

detai Is. 

Product-level Description 

Interfaces to other Software Products. 

Discuss external references to other 

software. 

Restrictions and Limitations. 

Discuss known restrictions and limitations 

introduced as a result of this program or 

enhancement* at the user* operator* and 

programmer I evel* 

Errors 

List all error diagnostics for the product* 

including severity level* significance* and 

corrective action for the user to take for 



STU 

STU 
STU 
STU 
STU 
STU 

STU 
STU 



STU 
STU 



STU 
STU 



STU 
STU 



STU 
STU 
STU 

STU 
STU 



STU 
STU 



1 
2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
3 8 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 



revi si on 



USERS GUIDE 

SOFTWARE DEVELOPMENT METHODOLOGY (SDM) 



3-13 
09/23/81 



3.0 DOCUMENTS 
3,6 ERS 



CODE 



12.39.01. 

LINE 



each error. 
6.0 Glossary (optional) 

Terms* abbreviations* or symbols 
special meaning In this document 



which Nave 



3.7 filfi 
Purposes 



Contents 



Audiences 



To describe the overall process performed by a 
software product or component. This description 
covers major processes* the flow of data through 
the product* and descriptions of the data objects 
that are manipulated* as net I as documentation at 
the module I evel — structure of the modules and the 
information that each passes or accesses. 

The GID consists of the Analysis Specification (AS) 
and the Design Specification (DS). 

Development Project 
Design Team 
Product Desi gn 
Evaluation 



Owners Product Desgn/Advanced Systems Design 
Authors Development Project 
Table of Contentss 

1.0 Introduction 

2.0 Analysis Specification 

2.1 Overview 

2.2 Data Flow Diagrams (DFDs) 

2.2.1 Context Diagram 

2.2.2 Level and lower DFDs 

2.2.3 Process Descriptions 

2.3 Data Structure Diagrams 
3.0 Data Dictionary 

4.0 Design Specification 

4.1 Structure Charts 

4.2 Module Descriptions 

4.3 Data Structure Diagrams (if needed) 
4*4 Design Issues 

5.0 References 
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Purpose: To list build schedules and testing plans for a 
given CCR or CPS release. 

Contents This plan outlines testing plans and requirements 
for a given Product Set build (in SOD). Only 
information that is not covered in other documents 
is noted here* One example of this type of 
information is installation testing planning* 
Performance test descriptions and size of a feature 
test base are examples of information that should 
not be included* since that information is 
available elsewhere. 

Audience: Managers 
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This outline is extracted from the proposed CDC 
Standard for system test plans CDC-STD 1.01*110* 
Please refer to that standard if more details are 
desired* 
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Applicable documents* 

Test Approach 

Testable conditions 

This subsection identifies the conditions 

that are to be tested in the software 

covered by the test plan. Examples 

include: 
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Stress Testing 
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3.9 IBS 
Purpose? 

Contents 



Usabi lity 
Compatibil I ty 
Security 
Functional Operation 



(features) 



3.2 Testing Selection 

This subsection defines a rationale for 
selecting which of the conditions 
identified in the section 3*1 are or are 
not to be tested* and identifies which are 
to be tested and which are not to be 
tested* This section may refer to 
individual feature test plans for details. 

3.3 Testing Procedures 

This subsection identifies the procedures 
that are to be used to execute tests* 
record results* report results* store test 
data and procedures* and document errors. 

4.0 Entrance and Exit Criteria 

There are three sets of criteria to be 
specified. These are: l) minimum criteria 
to be satisfied to enter and remain in the 
system testing phase* 2) the minimum 
criteria to be satisfied to exit the system 
testing phase* and 3) the criteria for the 
software to become certified. This section 
describes the criteria which apply. 

5.0 Resource Requirements 

a) Personnel Requirements* 

b) Hardware Requirements. 

c) Software and Tools Requirements. 

d) Other Requirements. 
6.0 Schedules/Costs 

7.0 Responsibilities 

Each activity described in the plan must be 
assigned to specific organizations or 
individuals. 



To describe the design of a product at 
The IMS is a deliverable and is also 
basis for product maintenance. 
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The IMS consists of the final GID 
Design Spec* and Data Dictionary). 
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